Conventional relational databases are well known and data collected in support of large enterprises is often collected into relational databases. For example, an enterprise with a sales operation might store all of their data relating to sales transactions in a relational database. A relational database structure defines the tables making up the relational database, along with definitions for the rows and columns of the tables and the relations between tables.
For example, a relational sales database might have an invoice table and a customer table. The invoice table might have columns for an invoice number, customer number, salesperson, sales date, shipping date, etc., with one row per “instance” in the table. In this example, an instance is an invoice. The customer table might have one row per unique customer, and columns for a customer number, customer name, address, credit limit, etc. As for the relations between tables, the relational sales database might relate customer numbers in the invoice table with customer numbers in the customer table.
Such relational structures are well known and methods for navigating large relational databases are known. For example, a user at a relational database client might formulate a Structured Query Language (“SQL”) statement and submit that SQL statement to a relational database server. The relational database server would respond to the submission with a table of results that matched the SQL statement. For example, a user might request a list of invoices for a given day listing the customer, the salesperson, and the amount for each such invoice. The list might be informative if the enterprise only makes a few sales per day, but is less likely to be informative if the enterprise makes thousands of sales per day.
To provide workers with informative views of an enterprise's data, analytical systems are often employed. One example of an analytical system is a data warehouse. A data warehouse contains much the same data as the relational database, but in a much different form. As should be apparent with the examples used above, adding one more invoice to the relational database could be as simple as adding a record with the invoice pertinent data to the invoice table.
For this reason, large relational databases used in this way are often referred to as on-line transaction processing (“OLTP”) systems. By contrast, the data warehouse usually stores data in aggregate, to allow for high-level analysis of the data. Often the data is aggregated according to multiple criteria, to provide access to data and aggregations much faster than if the same information were obtained from a relational database system.
Such systems of replicated and/or aggregated data are often referred to as on-line analytical processing (“OLAP”) systems. In a typical enterprise, the data warehouse is populated and updated periodically from the OLTP data. For example, U.S. Patent Publication No. 2003/0225798 shows a method of capturing data from on OLTP for data warehousing.
The updating process might, for example, provide invoice totals and other data extracted from the OLTP data to the OLAP data structures on a once-daily update. Using an OLAP system, a user might request a chart of the sales by geographic region broken down by month for a year's worth of data.
If such a request were to be made of the OLTP data structures, a server responding to that request would have to scan all the records in several tables to come up with totals for the chart. With one request, the scan might be easy, but when many requests are being made, it is more efficient to make those requests of an OLAP system, since the results for the chart may be obtained by taking the appropriate slice of data from the OLAP data structures. Sometimes, an OLAP data system is represented as a multi-dimensional data structure and each OLAP query is simply a “slice” through this multi-dimensional data structure.
In one common analytical application, a user is presented with a user interface at an OLAP client and uses that OLAP client to “navigate” a set of “cubes” (the multi-dimensional, or “MD” data structure) that were created from the OLTP data structures. Using that OLAP client, the user may navigate the OLAP data using top-down slicing and narrowing mechanisms, looking for points of interest within the information presented.
U.S. Pat. No. 6,480,842 shows a system, including a method for navigating between dimensions and domains, that allows for an interactive response to a query based on data stored in at least one on-line transaction processing (OLTP) database structure and data stored in at least one on-line analysis processing (OLAP) database structure. The system includes a dimension to domain server, which interacts with a user interface client, which presents to a user, representations of elements of the OLTP database structure and representations of elements of the OLAP database structure. The user interface client also includes logic to accept a selection of representations of elements selected by the user, and if the selection comprises more than one element, an association among the elements in the selection. An element relator is provided that relates one or more elements of the OLTP database structure to one or more elements of the OLAP processing database structure when the selection of representations includes at least one element from the OLTP database structure and at least one element from the OLAP database structure. A query formulator, coupled to the user interface client, formulates the query based on the selection and any associations. The query formulator is also coupled to the element relator when at least one association of the selection is an association between at least one element from the OLTP database structure and at least one element from the OLAP database structure. A query server receives the query from the query formulator and provides responses to the query received from the query formulator.
As the execution of queries in the OLTP database is expensive in terms of the required computational resources and due to the negative impact of such queries on the real-time capability of such an OLTP database, embodiment of the invention can provide an improved data processing system that reduces that amount of access operations to the OLTP database, while providing a user with most up-to date data for analytical purposes.